https://modernanalyst.com RSS feeds for Business Analyst Community & Resources | Modern Analyst 60 https://modernanalyst.com/Resources/Articles/tabid/115/ID/126/Requirements-by-Collaboration-Getting-it-Right-the-First-Time.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=126 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=126&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/126/Requirements-by-Collaboration-Getting-it-Right-the-First-Time.aspx We know that we must involve all the stakeholders if we want to discover a project’s requirements. But we need some guidelines on how to involve the right people and, given how busy everyone is, how to minimize the time and maximize the result. In this article, requirements expert Ellen Gottesdiener (www.ebgconsulting.com) shares her considerable experience running requirements workshops.   There is plenty of hard and anecdotal evidence that the most critical factor for your product’s success is your stakeholders’ involvement in defining requirements. Put another way, insufficient stakeholder involvement is often cited as causing erroneous requirements and project failure. Why do we often fail to exploit this rich resource? As a longtime requirements facilitator and consultant, I think I know. Project stakeholders—those who affect or are affected by the software—have diverse and even conflicting needs and viewpoints that complicate the already slippery slope of discovery and ambiguity that often characterizes requirements development. In other words, getting stakeholder input is hard, and we often don’t know how to do it effectively. A technique I’ve used many times in various industries and types of organizations is to hold collaborative workshops. You can use workshops for many purposes—for example, to outline the project’s vision and scope, to create a release strategy or iteration plan, or to define requirements in varying levels of detail. The beauty of this technique is that it creates an efficient, controlled, and dynamic setting where you can quickly elicit, prioritize, and agree on a set of high-quality project requirements. This column explains a key aspect of collaborative requirements workshops: identifying who should participate and outlining their roles. Author: Ellen Gottesdiener ellengott Sat, 29 Sep 2007 18:34:00 GMT f1397696-738c-4295-afcd-943feb885714:126 https://modernanalyst.com/Resources/Articles/tabid/115/ID/125/Use-Cases-Best-Practices.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=125 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=125&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/125/Use-Cases-Best-Practices.aspx A whitepaper written by requirements expert Ellen Gottesdiener of EBG Consulting (www.ebgconsulting.com) for IBM/Rational Software. As an analyst, you have the crucial task of defining the requirements for software that is to be built or acquired. Your task is crucial for a number of reasons. If software teams fail to define excellent requirements, projects suffer from a variety of problems, including quality shortfalls, failure to meet schedules, ever-expanding user requirements, and, in the end, customer dissatisfaction. The financial costs are enormous. Depending on which study you read, typical software projects spend roughly one-third of their overall budget correcting errors that originate in requirements. Whether you are defining requirements for new software, software that will be purchased, or existing software to be enhanced or maintained, it’s easy to see why a clear understanding of requirements is one of the most important determiners of project success. Moreover, the task of defining high-quality requirements is crucial to all the project stakeholders: clients, end users, developers, testers, and managers. Years of experience in defining requirements have led to the development of a number of techniques and models to assist in the process. Among these, perhaps the most well-known model is the use case, the focus of this paper. If you have experience with use cases, you know how pivotal they are for supporting many project activities, and you may be wondering how to improve your use case modeling to save time and energy. If you are new to use cases, you want to know the bottom line best practices for getting started. This paper’s goal is to provide practical advice to both novice and experienced use case modelers. Author: Ellen Gottesdiener ellengott Sat, 29 Sep 2007 18:32:00 GMT f1397696-738c-4295-afcd-943feb885714:125 https://modernanalyst.com/Resources/Articles/tabid/115/ID/124/Abuse-Case-Guidelines.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=124 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=124&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/124/Abuse-Case-Guidelines.aspx A set of 25 serious (and somewhat cynical) guides for abusing use cases by requirements expert Ellen Gottesdiener, of EBG Consulting, Inc. (www.ebgconsulting.com). Author: Ellen Gottesdiener ellengott Sat, 29 Sep 2007 18:09:00 GMT f1397696-738c-4295-afcd-943feb885714:124 https://modernanalyst.com/Resources/Articles/tabid/115/ID/88/Adapting-Your-Requirements-Practices--Part-2-of-2.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=88 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=88&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/88/Adapting-Your-Requirements-Practices--Part-2-of-2.aspx In part 1 of this article EBG Consulting's Ellen Gottesdiener discussed the need to adapt your requirements practices to your product and project. In part 2, she explores additional issues for tailoring requirements development and management. Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 18:00:00 GMT f1397696-738c-4295-afcd-943feb885714:88 https://modernanalyst.com/Resources/Articles/tabid/115/ID/87/Adapting-Your-Requirements-Practices--Part-1-of-2.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=87 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=87&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/87/Adapting-Your-Requirements-Practices--Part-1-of-2.aspx Should your requirements practices embrace the change-driven approach of agile methods--lightweight models, minimal documentation, and little process? Or should you take a risk-driven approach--robust models, careful validation, and rich documentation? In this two-part weekly column, EBG Consulting's Ellen Gottesdiener explains that you should tailor your requirements practices to your project and product. Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 17:45:00 GMT f1397696-738c-4295-afcd-943feb885714:87 https://modernanalyst.com/Resources/Articles/tabid/115/ID/86/Debating-Use-Cases-and-Requirements.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=86 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=86&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/86/Debating-Use-Cases-and-Requirements.aspx Read about the lively Use Case Panel: Discussion Among the Gurus - a panel held at the 2002 Rational Users Conference. "Doug Rosenberg wouldn't have a 20-page use case. Ian Spence would. But, as Ellen Gottesdiener reminded the panel, it's not all about size. Welcome to the Use Case Panel: Discussion Among Use Case Gurus. And what a panel it was. On hand for the Wednesday RUC 2002 event were Ivar Jacobson and Ian Spence from Rational Software, Ellen Gottesdiener from EBG Consulting, Inc., Doug Rosenberg from ICONIX Software, Elemer Magaziner from Project Linguistics, Intl., and Steve Adolph, from WSA Consulting, Inc. If any of the lightning flashing around Orlando today were to have stuck this room, there'd be no one left to write articles about use cases. The panel responded to questions submitted earlier in the week via the Rational public site and the Rational Developer Network. And, as you would expect, there was some agreement, a few disagreements, and an occasional debate, all of it ably moderated by Kurt Bittner from Rational." Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 17:32:00 GMT f1397696-738c-4295-afcd-943feb885714:86 https://modernanalyst.com/Resources/Articles/tabid/115/ID/85/Use-Cases-Best-Practices.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=85 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=85&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/85/Use-Cases-Best-Practices.aspx Years of experience in defining requirements have led to the development of a number of techniques and models to assist in the process. Among these, perhaps the most well-known model is the use case, the focus of this paper. If you have experience with use cases, you know how pivotal they are for supporting many project activities, and you may be wondering how to improve your use case modeling to save time and energy. If you are new to use cases, you want to know the bottom line best practices for getting started. In this white paper, requirements expert Ellen Gottesdiener of EBG Consulting provides practical advice to both novice and experienced use case modelers.  Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 17:25:00 GMT f1397696-738c-4295-afcd-943feb885714:85 https://modernanalyst.com/Resources/Articles/tabid/115/ID/84/Collaborate-for-Quality-Using-Workshops-to-Determine-Your-Projects-Requirements.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=84 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=84&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/84/Collaborate-for-Quality-Using-Workshops-to-Determine-Your-Projects-Requirements.aspx Just how important is it to fully develop your project’s requirements? After all, nailing down your requirements usually takes only 8% to 15% of your overall project effort. Truth be told, it’s not really something you’ll want to spend your resources and energy on—unless, that is, you care at all about the quality of your product, your customers’ level of satisfaction, and the amount of post-implementation repair you’ll have to take care of down the road. Why is it so important to get requirements right? For one thing, you’re likely to introduce more defects into your software product in the requirements phase than in any other phase—and these defects account for as much as half of the product’s total defects. Defects originating in requirements are harder to remove than defects originating in any other phase. But that’s not all. Fixing them later in the project will cost you more, too—as much as 100 times more after implementation than if you detected and corrected them in the requirements phase. It’s no wonder that rework due to requirements defects can eat up as much as 50% of your overall budget. One other aspect of low-quality requirements is harder to measure, but just as treacherous. It’s called “scope creep,” and it’s cited as the most vexing problem in software development. Unrestrained by carefully developed requirements and mutual IT-customer or product development agreement, the scope of the project keeps creeping—expanding as the work proceeds. For all these reasons, project teams are searching for ways to develop requirements that are as free from defects as possible. One way to develop high-quality requirements is based on the use of collaborative workshops along with walkthroughs and QA checklists. As this article will illustrate, that combination of best practices gives you a powerful and efficient way to deliver quality user requirements—and, by extension, quality software products. Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 17:13:00 GMT f1397696-738c-4295-afcd-943feb885714:84 https://modernanalyst.com/Resources/Articles/tabid/115/ID/81/Why-Arent-YOU-Doing-Requirements-Right.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=81 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=81&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/81/Why-Arent-YOU-Doing-Requirements-Right.aspx This article explores the top nine reasons the author, requirements expert Ellen Gottesdiener, has heard for NOT doing requirements right -- and how to address these reasons in response.  Author: Ellen Gottesdiener ellengott Fri, 14 Sep 2007 16:56:00 GMT f1397696-738c-4295-afcd-943feb885714:81 https://modernanalyst.com/Resources/Articles/tabid/115/ID/50/Prioritization-Puzzles-Practices-for-Prioritizing-Your-Product-Requirements.aspx#Comments 0 https://modernanalyst.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=115&ModuleID=572&ArticleID=50 https://modernanalyst.com:443/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=50&PortalID=0&TabID=115 https://modernanalyst.com/Resources/Articles/tabid/115/ID/50/Prioritization-Puzzles-Practices-for-Prioritizing-Your-Product-Requirements.aspx Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement—or whether you should delve into them at all—you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on requirements you won't use? In this article, Ellen Gottesdiener answers the question by detailing how and when requirements should be dealt with. Author: Ellen Gottesdiener ellengott Mon, 13 Aug 2007 18:48:00 GMT f1397696-738c-4295-afcd-943feb885714:50